Subject: Comments on AIW minutes

From: [email-masked]
Date: Fri, 13 May 94 10:40:58 EDT

Wayne,
I have a few comments both on what was discussed in Anaheim and some
discussions in our team since then.  I've imbedded them in the minutes.
Peter

> 8.     Capabilities - Wayne Clark
>
>      a.     Agenda   Review of AIW #3 consensus items,
> Review capabilities exchange format proposal, Discuss
> capabilities exchange protocol issues, TCP connection
> proposal, Summary and identify next steps
>
>      b.     Review of AIW #3 consensus items
>        1)  Shall DLSw be broken up into a base set +
> option sets? Yes
>        2)  What feature comprise the base set?
> Base = RFC 1434 - NetBIOS (optional) + base MIB +
> D(Flow Control SIGlet) + D(Connect SIGlet)
>        3)  What features comprise the option sets?
> NetBIOS, Loop Prevention, Priority/COS, Advanced Flow
> Control, MAC Address list (at CANUREACH time)
>        4)  Should a vendor ID be included in the
> capabilities exchange?  Yes
>        5)  Should the capabilities exchange be carried
> over TCP or UDP?  TCP
>        6)  Is it desireable to have a directory server /
> name server?  Minimal one - see MAC address list
>        7)  Should CANUREACH / ICANREACH be optional?
> n/a
>        8)  Format of the capabilities exchange?
> Generalized data stream (GDS) variables with structured
> subfields
>
>      c.     Review capabilities exchange format
> proposal:
>           (The following is a summary of Wayne Clark's
> posted proposal.)
>
> --------------------------------------------------------
> | LL | ID=F000 | Capabilities Exchange Control Vectors |
> --------------------------------------------------------
>
> 0-1     Length of GDS variable
> 2-3     GDS ID: X'F000'
> 4-n     Control vectors
>
> Capabilities Exchange Control Vectors include
> o     5 bytes for vendor ID (X'81')
> o     n bytes for version string (X'82')
> o     3 bytes for NetBIOS support (X'83')
> o     3 bytes for Loop Prevention (X'84')
> o     4 bytes for Flow Control Support (X'85')
> o     4 bytes for Initial Pacing Window (IPW) (X'86')
> o     8 bytes for MAC address masks (X'87')
> o     8 bytes for MAC address value (X'88')
> o     Sets of n bytes for MAC address lists (X'89')
>
> Changes at meeting:
>      Eliminated flow control support vector
>      Combined MAC address mask and MAC address value

A few weeks ago I suggested combining the list with the mask, and
most commenters seemed to like that idea.

>      Added 8A for NetBIOS name - needs padding rule,
> stars
>      Added 8B exclusivity in MAC/NetBIOS list

We spent some time as promised working on 8A padding and wildcarding
rules.  While this wasn't hard, defining inclusivity/exclusivity and
how the NB name list might be used proved to be quite difficult.  The
IBM team is of a mind that 8A and (8B for NetBIOS) aren't worth doing
right now, so we are wondering if anyone would object to dropping them.

>      Only vendor ID and initial pacing window are
> required; others are optional

I thought we also agreed to a "DLSw version" CV which would be a
required CV.

>
>      d.  Format-related issues
>
>        1)  GDS variables:
>             - ID(s) to be assigned by the Architecture
> Reference SIG after we reach AP status
>             - We need to decide on what comprises a GDS
> variable (below) to determine the number of variables we
> need
>             - GDS variable patent is not an issue since
> DLSw won't use the continuation bit
>
>        2)  Control vectors
>            - IDs can be assigned by DLSw alone
>            - Use the range X'80' - X'FF' since the
> control vectors are tied to a particular GDS variable

The actual range we can use is x'80'-x'FD'.  x'FE' and x'FF' turn out
to be reserved values.

>            - Do we want a DLSw-specified range and a
> vendor-unique range?  Decided NO, have a vendor control
> vector.

I don't think we thought about this enough.  We have 126 possible
capex CV id's of which the RIG has defined 11 or so.  I find it hard to
believe the standard in its life will ever come close to using even
half the number available, and yet we want to leave ourselves only one
value for all vendor-unique capabilities?  This means we will each have
to define some other scheme to be to exchange more than one of our own
capabilities.

I would like to propose reserving x'D0'-x'FD' for vendor-unique stuff -
that's 46 code points, leaving 80 for the standard.  This approach
allows vendors to migrate proprietary stuff into the standard domain
later simply by changing the code point.  It would also make it easy
for multiple vendors to share a capability that may not have been
adopted yet as part of the standard.

>            - Should the "L" be inclusive for type LT
> control vectors?  Yes
>            - Do we want to use multiple-instance control
> vectors (for example, with the MAC address list CV)?
> Yes (see above)
>
>        3)  Switch-to-switch protocol (SSP) message
> details
>            - We need an SSP message type assigned for
> capabilities exchange.  In the interim, will use 'x20'

I feel that this SSP message type should mean "GDS variable" and
NOT "capabilities exchange".  If we let it be the latter, then
we have set the precedent of having to pick a new SSP message type
for every new GDS variable we define (e.g., the Reject message we
discussed in Anaheim).  It would defeat the purpose of a GDS id.

>            - Should we use long or short SSP message
> headers?  Short.  All FF for unused fields
>
>        4)  Specific control vector issues
>            - Should version string CV be required?
> Allowed, not required
>            - Should a vendor-unique data DV be required?
> Optional
>            - Dow we want a supported SAP list CV?  Wait
> for FSM contributions / changes from Connect RIGlet

I don't understand how the supported SAP list CV idea is related to
any FSMs or what is going on in the Connect RIGlet.

>            - Do we want a NetBIOS name CV similar to the
> MAC address list CV?  Yes.  Contribution from Gene Cox,
> IBM.

See my comment above on this topic.

>            - Do we want both a MAC address list and (MAC
> Address Mask CV and MAC Address Value CV)?  Yes

See my comment above on this topic.

>            - General concern taken into account on these
> issues:  how much to specify to increase
> interoperability versus how much room to leave to
> innovate, compete, and adapt to specific markets
>
>        5)  Single versus multiple GDS variables
>            - Various options exist (single GDS variable
> with individual variables in CVs, multiple GDS variables
> with individual variables in CVs logically grouped
> together, multiple GDS variables with no CVs, a
> variation of single GDS variable with multiple-instance
> CVs)   Selected Single GDS variable with multiple
> instance subvectors
>            - Possible limitations for long lists of MAC
> addresses and/or NetBIOS names
>
>        6)  Capabilities exchange format errors
>            - Malformed GDS Variable:  Invalid GDS
> length--not in the range of (4 + length of required CVs)
> to length of message, Invalid GDS ID, Length of CVs
> doesn't match length of GDS variable.
>            - Invalid control vector ID
>            - Malformed control vectors: length doesn't
> match CV requirements, invalid value in CV data
>            - Duplicate CVs (for non-repeating CVs)
>            - Out-of-sequence CVs (if multiple-instance
> CVs allowed)

I thought we agreed on the existence and format of some sort of
Reject message, including whether it would have error codes or
an offset to the offending field.  I can't remember the specifics.

>
>        (The next six issues are protocol-related issues)
>
>        7)  Lack of a capabilities exchange?  indicates
> back rev DLSw
>
>        8)  What other conditions indicate a back rev?
> Receiving a non-capabilities exchanges SSP message
>
>        9)  How long does a DLSw wait for a capabilties
> exchange before declaring it back rev?

I think we decided that the time to wait was to be product-specific.

>
>      10)  When should capabilities be exchanged -- only
> at start-up or during run-time?

I think we decided it was optional to support them during run-time.
I need to think more about this, but it may be important to initially
exchange with a partner whether you can support run-time changes.

>
>      11)  What are the required CVs?  Vendor ID, Version
> string
>
>      12)  What happesn when a capabilities exchange
> error is detected? (options include:  Log the error
> locally and drop the connection; Remote sense code an
> dleave connection up; Remote sense code and drop the
> connection)

Again, I thought we had decided something here but perhaps not.

>
>      13)  Organizationally-unique identifiers:  Current
> assignment contained in RFC 1340 (reference section
> titled "Ethernet Vendor Address Components").  If your
> organization does not have an OUI, contact Joyce K.
> Reynolds, Internet Assigned Numbers Authority, USC /
> Information Sciences Institute, 4676 Admiralty Way,
> Marina Del Rey, CA  90292-6695,  (213) 822-1511,
> [email-masked]
>

I believe OUIs are assigned by the IEEE, and not by the IANA.  There
may also be a fee involved.  Dave Chen, an IBMer who has been looking
at the DLSw MIB, suggested to me that we consider using an SNMP object
identifier in the vendor part of the tree to identify a vendor (and
even possibly to replace the "version string" CV).  A vendor could
manage its own object id's to identify whatever it wanted all in one
string:  vendor, product, release,...  This might be worth considering
(at least for identifying a vendor) if it's difficult or expensive to
get an OUI - I really don't know.

Peter